It is well-known to operate interrupt controllers (e.g., in a personal computer system) in a master-slave fashion. A specification for doing so has been adopted by a consortium of companies, including the assignee of the present invention, National Semiconductor Corporation. That specification is entitled "Serialized IRQ Support for PCI Systems" (revision 6.0; Sep. 1, 1995) and is hereby incorporated by reference in its entirety.
In accordance with the Specification, an interrupt request may be received at a slave controller, and the request is then communicated as an "IRQ value" to a host (also sometimes called"master") controller. (The controllers may also have their send data lines wired together, as shown in FIG. 4.1 of the Specification.) Communication of IRQ values from a slave controller to the host controller is serialized. That is, communication is over a single line. IRQ value messages are bracketed by start and stop frames, which are signified by predetermined periods of low signal on the serial line. For example, when the serial communication is initially in an idle state, a START frame may be indicated by four to eight clock cycles of the signal on the line being low and then a transition to high. The first low cycle in a START frame would generally be generated by either the slave (quiet mode) or master (continuous mode), and the remaining low cycles in the START frame are generated by the master.
The data portion of the message consists of a series of low and high signals to indicate, for example, a particular IRQ value. Specifically, during a series of cycles of transmission of the data portion, the line may be either low for a particular cycle or stay high for that cycle.
Finally, a STOP frame is generated by the master, and is indicated by two to three cycles of the wire being low. A STOP frame indicates that, at the next cycle, the master will be in IDLE mode again.
So, for example, referring to FIG. 1, if the slave is in IDLE mode at point A, a down edge at point B followed by an up edge at point C will cause the slave to go to "SHIFT_IRQ" (DATA TRANSFER) mode. Finally, after the proper number of data bits have been transmitted, a down edge at point D followed by an up edge at point E will cause the slave to go back to IDLE mode.
A significant disadvantage of these prior art implementations, however, is that they assume the master and slave are always synchronized to each other. If the master and slave fall out of synchronization, it is difficult if not impossible to resynchronize them. FIG. 2 shows an example of the slave controller being in IDLE mode at point R, when a down edge at point S followed by an up edge at point T causes the slave controller to go into the data transfer mode. This is even though the down edge at point S followed by the up edge at point T constitutes a STOP frame, and not a START frame. Furthermore, the START frame constituted by the down edge at point U followed by the up edge at point V causes the slave to go into an IDLE mode, rather than into DATA TRANSFER mode, as desired.
FIG. 3 illustrates a situation where the slave controller is in a DATA TRANSFER mode (at point X) when it receives a start pulse. The slave controller interprets the down edge at point Y followed by the up edge at point Z as a STOP pulse, even though the Y-Z pulse is intended by the master controller as a START pulse. Therefore, the slave controller goes into IDLE mode, rather than into DATA TRANSFER mode as intended.
As yet another example, FIG. 4 illustrates a situation where at point d the slave controller is in DATA TRANSFER mode. The STOP pulse, constituted by the down edge at point e followed by the up edge at point f, is ignored by the slave controller because it comes earlier than expected (as indicated by a data frame count or transfer time limit). Thereafter, the master controller and the slave controller are hopelessly out of synchronization with each other as can be seen from the examples of FIGS. 2 and 3.